home *** CD-ROM | disk | FTP | other *** search
/ ftp.cs.arizona.edu / ftp.cs.arizona.edu.tar / ftp.cs.arizona.edu / icon / newsgrp / group96b.txt / 000055_icon-group-sender _Fri Nov 8 22:00:52 1996.msg < prev    next >
Internet Message Format  |  1997-01-02  |  3KB
  1. Received: by cheltenham.cs.arizona.edu; Mon, 11 Nov 1996 10:00:16 MST
  2. To: icon-group@cs.arizona.edu
  3. Date: 8 Nov 1996 22:00:52 -0700
  4. From: dps@azstarnet.com (dave  schaumann)
  5. Message-Id: <561364$hcf@web.azstarnet.com>
  6. Organization: Starnet, Tucson, Az.
  7. Sender: icon-group-request@cs.arizona.edu
  8. References: <55qhto$66r@netty.york.ac.uk>
  9. Subject: Re: sets and structures
  10. Errors-To: icon-group-errors@cs.arizona.edu
  11.  
  12. In article <55qhto$66r@netty.york.ac.uk>,
  13. stephen parker <stephen@lila.york.ac.uk> wrote:
  14. >i'm reading ``An Overview of the Icon Programming Language; Version 8''
  15. >(Griswold).  the section on sets says: ``insert(S, x) has no effect if x
  16. >is already in S''.
  17.  
  18. This is absolutely true.  What you're not understanding is what
  19. the phrase 'x is already in S' means.
  20.  
  21. There are two ways that values can be implemented: mutable or
  22. immutable.
  23.  
  24. If a type is immutable, values of that type are unique and cannot be
  25. changed.  Any operation that changes the value creates a new instance
  26. of that type (as opposed to merely changing the old value in some way).
  27. Integers are an example of an immutable type.
  28.  
  29. Conversely, if a type is mutable, values are not unique, and operations
  30. on the value change the value.
  31.  
  32. This will probably be cleared up by an example.  Consider the following
  33. pseudo code:
  34.  
  35.    x := some_value;
  36.    y := x;
  37.  
  38.    x := some operation on x
  39.  
  40.    if (y is still the same value as x)
  41.      then the value of x (and y) is of mutable type
  42.    else
  43.      the values of x (and y) are of immutable type
  44.  
  45. thus,
  46.  
  47.    x := 3;
  48.    y := x;
  49.  
  50.    x := x + 1;
  51.  
  52.    # x ~= y here, so integers are of immutable type
  53.    # Each value of an immutable type is unique, so whenever you
  54.    # name it, you get the same value.  Each integer value 3 is
  55.    # the same as any other integer value 3.
  56.  
  57.    x := []
  58.    y := x
  59.  
  60.    put(x, 3)
  61.  
  62.    # x is still the same list as y here, so lists are mutable.
  63.    # Values in a mutable type are *not* unique, and typically
  64.    # each time you name a value in a mutable type, you get a new
  65.    # and unique value, even if the name is the same.  Hence,
  66.    # in the following code
  67.  
  68.    x := []
  69.    y := []
  70.  
  71.    # x and y have different values, even though they were
  72.    # created from the same name.  If this code is executed
  73.    # in a loop, x and y will be assigned with two new values,
  74.    # each different from all the other values.  Thus, it doesn't
  75.    # matter if you write
  76.  
  77.    s := set();
  78.    insert(s, [])
  79.    insert(s, [])
  80.  
  81.    # or you write
  82.  
  83.    s := set();
  84.    every 1 to 2 do
  85.       insert(s, [])
  86.  
  87.    # both code fragments insert two different lists into the set.
  88.  
  89. >so, what's the answer if you want to form a set of non-atomic types?
  90. >do i have to do it by hand?
  91.  
  92. Yup.  I'm not aware of any data structure that makes it easy (or fast)
  93. to deal with sets containg elements that are not easy to compare (like
  94. lists).
  95.  
  96. >i suppose the answer is to buy the book -- i will when i have chance.
  97.  
  98. That would be an excellent idea.  Icon is a very cool language, but
  99. it does have some pitfalls you can easily fall into.
  100.  
  101. -Dave
  102.  
  103.  
  104.  
  105. -- 
  106. No matter how much we ask after the truth, self-awareness is
  107. often unpleasant.  We do not feel kindly toward the Truthsayer.
  108.  
  109.                                               -- Frank Herbert
  110.